These last decades have seen a rapid increase in applications on communication networks, first of all on cable networks and then, more recently, on wireless networks. Very rapidly, needs for making communications reliable have made themselves felt. At the beginning of the nineties, a transmission protocol was proposed to ensure reliability of transmissions. This protocol, referred to as TCP (RFC-793, Transport Control Protocol), proposes several reliability mechanisms. Among these reliability mechanisms, there are a congestion control mechanism for providing equitable sharing of bandwidth between various applications using the same communication network and an error control mechanism ensuring a reliable transport of each data item transmitted. The data being transmitted in the form of an ordered series of packets, an out-of-order reception of the transmitted data is identified as a transmission error by the error control mechanism, each transmission error causing a reaction of the congestion control mechanism resulting in general in a reduction in the data transmission rate. The TCP protocol spread widely on networks to the point that this protocol is now considered to be essential for ensuring global stability of communication networks.
In defining the TCP protocol, applications existing at the time of its creation were considered. The TCP protocol has not therefore taken into account a recent appearance of communication applications on mobile appliances, nor the fact that the same appliance can communicate simultaneously on several communication paths such as cable links (Ethernet, IEEE1394) and/or wireless links (Wi-Fi, 3G, 4G, Bluetooth) in accordance with a multipath communication mode, each path being associated with an IP address (RFC 791: Internet Protocol) that is particular to it. The reliability of mechanisms of the TCP protocol are not suited to the multipath communication mode, since this communication mode on a plurality of paths may cause out-of-order receptions of packets that would be wrongly interpreted as transmission errors by the TCP reliability mechanisms.
Recently, a new protocol enabling communication appliances to benefit from a multipath communication mode was specified. This protocol, referred to as MPTCP (RFC-6824, Multipath TCP) can be seen as a development of the TCP protocol. In defining the MPTCP protocol, account was taken of two major requirements: compatibility with applications and compatibility with the network.
Compatibility of applications means that applications functioning with the TCP protocol must be able to function with the MPTCP protocol without modification.
Compatibility vis-à-vis the network means that the MPTCP protocol must be able to function on any network path on which TCP functions. Many network paths comprise intermediate network components (INCs) (“middleboxes”) such as network address translators (NATs), firewalls, proxies, gateways, etc. The INCs may be positioned in a local network of the LAN (Local Area Network) type or in an extended network of the WAN (Wide Area Network) type. Unlike routers, when TCP traffic passes through an INC the INC is capable of recognising the TCP traffic. This knowledge enables the INC to apply particular processing operations to the TCP traffic, such as accelerated processing or transfer mechanisms used in general by hardware accelerators. The MPTCP protocol must be able to benefit from the same accelerated processing or transfer mechanisms as the TCP protocol.
The MPTCP protocol is subject to certain limitations. For example, one characteristic of the MPTCP protocol is that it requires that a first network unit, which we shall refer to the “source” hereinafter, and a second network unit, which we shall refer to as the “receiver” hereinafter, the source and receiver being associated with the same connection, both support the MPTCP protocol. Such a restriction could limit the use of the MPTCP protocol, for example when a source implementing the MPTCP protocol wishes to communicate with a receiver not knowing the MPTCP protocol but for example only the TCP protocol.
Moreover, the MPTCP protocol is particularly suited when the network connecting a source and a receiver consists of a plurality of paths parallel from end to end. The MPTCP protocol is less effective when a portion of the network connecting the source and the receiver consists of a single path.
Various solutions have been proposed for overcoming the above restrictions. For example, when at least one portion of the network connecting a source and a receiver compatible with the MPTCP protocol consists of a single path, a first solution consists of encapsulating TCP subflows of a MPTCP connection, which we refer to as an “MPTCP subflow” hereinafter, in a single flow on the portion of the network consisting of a single path. The single flow is then managed by a single-path transport protocol, such as TCP, the MPTCP subflows encapsulated in the single flow being considered to be data of the single flow. This first solution is in general considered to be expensive in computing terms, but also in terms of memory use. This is because it requires firstly encapsulating each packet of each MPTCP subflow and secondly storing each packet of all the encapsulated MPTCP subflows as long as an error check mechanism of the encapsulation protocol has not checked that the packets have indeed been received. In addition, a loss of a packet in the single flow in general causes a global reaction of the congestion control mechanism of the encapsulation protocol and therefore a reduction in transmission rate in all the encapsulated MPTCP subflows, whereas the packet loss might affect only one MPTCP subflow among the encapsulated MPTCP subflows. Moreover, this solution requires the introduction into the network of at least one network unit able to make encapsulations. It may be added that, during an encapsulation, the network units able to make encapsulations do not use accelerated processing and transfer mechanisms like conventional INCs.
A second solution allows avoiding the incompatibility of a source or receiver with the MPTCP protocol. This second solution consists of inserting in a network an intermediate network unit, such as an INC, capable of providing a relay between a multipath connection such as for example an MPTCP connection and at least one single-path connection such as for example a TCP or UDP connection. The INCs capable of providing a relay between an MPTCP connection and at least one TCP connection are known by the term “TCP/MPTCP relay”. A TCP/MPTCP relay is able to match a TCP flow of a TCP connection, which we refer to hereinafter simply as “TCP flow”, with an MPTCP flow. A TCP/MPTCP relay thus enables a source (or respectively a receiver) using the MPTCP protocol (which we shall refer to hereinafter as “MPTCP source (or respectively receiver)”) to communicate with a receiver (or respectively a source) using the TCP protocol (which we shall refer to hereinafter as “TCP receiver (or respectively source)”). When a TCP/MPTCP relay receives a packet of an MPTCP subflow (which we shall refer to hereinafter as “MPTCP packet”) coming from an MPTCP source, the relay extracts the data contained in the MPTCP packet, inserts them in a packet of a TCP stream (which we shall refer to hereinafter as “TCP packet”), and transmits the TCP packet in the direction of the TCP receiver in the TCP flow. When a TCP/MPTCP relay receives a TCP packet coming from a TCP source, the relay extracts the data contained in the TCP packet, inserts these data in the MPTCP packet and transmits the MPTCP packet in the direction of the MPTCP receiver in an MPTCP subflow.
The major drawback of this solution is requiring the installation of TCP/MPTCP relays in the networks. In addition, these relays do not use processing and transfer accelerations like conventional INCs.
Use of the MPTCP protocol comprises three main phases:                a phase of establishing a connection,        a phase of transferring data packets in the context of the connection established, and        a phase of dropping the connection.        
The establishment of an MPTCP connection begins with a procedure known as “three-way handshake” comprising the following steps implemented sequentially:                the sending of a source synchronisation packet, referred to as “SYN packet”, by a source in the direction of a receiver,        the sending of a receiver synchronisation packet referred to as “SYN/ACK packet”, by the receiver in the direction of the source, this packet also providing acknowledgement of the source synchronisation packet, i.e. the SYN packet, and        the sending of a packet acknowledging the destination synchronisation packet (i.e. the SYN/ACK packet), referred to as “ACK packet”, by the source in the direction of the receiver.        
The connection is established when the receiver receives the ACK packet. Each packet transmitted in the context of an MPTCP connection is transmitted in an MPTCP subflow. An MPTCP subflow is identified by a quintuplet per connection direction defined during the connection establishment phase. In the direction source to receiver (or respectively receiver to source), this quintuplet comprises a source IP address and a receiver IP address, a source port number, a receiver port number and an identifier of the receiver IP address (or respectively an identifier of the source address). Hereinafter, for simplification, we shall consider that an MPTCP subflow is identified by a sextuplet comprising the source IP address, the receiver IP address, the source port number, the receiver port number, the identifier of the receiver IP address and the identifier of the source IP address. It should be noted that the identifier of the source IP address and the identifier of the receiver IP address enable the source and receiver to find the values of source and receiver IP addresses when network address translators NATs are present in the network.
The data packet transfer phase uses the IP addresses and the port numbers defined during the connection establishment phase. This phase benefits fully from acceleration mechanisms in the INCs.
During the phase of dropping a connection, the connection is dropped either abruptly by exchange of a packet of the “reset” type, referred to as an “RST” packet, or more evenly, by exchange of a packet of the “FIN” type, hereinafter referred to as “FIN packet”, between the source and the receiver.
Whereas a connection according to the TCP protocol can be associated with only one data flow, a connection according to the MPTCP protocol may comprise a plurality of MPTCP subflows. A data transfer application using an MPTCP connection can then at any time use any of the MPTCP subflows.
An MPTCP connection comprising a plurality of MPTCP subflows is established in a plurality of steps comprising a creation of an initial subflow and then a creation of at least one additional subflow.
FIG. 1 shows schematically an example of use of the MPTCP protocol during the creation of an MPTCP connection comprising an initial MPTCP subflow and an additional MPTCP subflow. This embodiment takes place in a network comprising four INCs 1002 to 1005, and a first network unit 1001 and a second network unit 1006 compatible with the MPTCP protocol. The network units 1001 and 1006 can alternately fulfil a role of source or receiver. Hereinafter we focus on the case where the network unit 1001 fulfils a role of source and where the network unit 1006 fulfils a role of receiver (in some embodiments). All the methods described hereinafter are however reversible (in other embodiments) and suited to the case where the network unit 1001 fulfils the role of a receiver and the network unit 1006 fulfils the role of a source. The network unit 1001 is then referred to as the source 1001, and the network unit 1006 the source 1006. The source 1001 is situated in a LAN, referred to as “source LAN”, comprising the source 1001 and the INC 1002. The receiver 1006 is situated in a LAN, referred to as a “receiver LAN”, comprising the receiver 1006 and the INC 1005. The two LANS are connected to a WAN comprising the INCs 1003 and 1004. The initial MPTCP subflow is created during a phase of establishing an MPTCP connection. A creation of the initial MPTCP subflow uses a three-way handshake 110, 111 and 112 in which the SYN, SYN/ACK and ACK packets comprise a header of the MP_CAPABLE type. From the point of view of the MPTCP protocol, the header MP_CAPABLE must absolutely be situated in the SYN, SYN/ACK and ACK packets when the initial MPTCP subflow is created. However, a TCP receiver that receives a packet containing the MP_CAPABLE header would not be able to interpret the MP_CAPABLE header and would ignore this header. An exchange of packets containing the MP_CAPABLE header allows firstly to ensure that the source and receiver can implement the MPTCP protocol and secondly to create the initial subflow.
The additional subflow is created following the creation of the initial subflow by implementing a three-way handshake procedure 120, 121 and 122 in which the SYN, SYN/ACK and ACK packets comprise a header of the MP_JOIN type. From the point of view of the MPTCP protocol, the MP_JOIN header must absolutely be in the SYN/ACK and ACK packets when the additional subflow is created. However, a TCP receiver receiving a packet containing the MP_JOIN header would not be able to interpret the MP_JOIN header and would ignore this header.
The example embodiment in FIG. 1 describes the creation of a single additional MPTCP subflow. Other additional MPTCP subflows may be created, according to the number of IP addresses available on the source and on the receiver.
The creation of additional MPTCP subflows may be dynamic according to the availability of transmission paths that can be used for the MPTCP connection.
Each MPTCP subflow is associated with a sextuplet that is particular to it.
The TCP error check and congestion control mechanisms have been adapted in order to take into account the specificities of the multipath context.
As seen above, the MPTCP protocol is suited to the dynamic management of the opening up of new communication paths or the closure of existing communication paths. However, it is necessary for these paths to be end-to-end, that is to say from the source to the receiver. FIG. 2A shows schematically an example of a communication network 100 in which communications between a source 101 and a receiver 108 are managed by the MPTCP protocol. The communication network 100 comprises six nodes of the INC type numbered 102 to 107, a source 101 compatible with the MPTCP protocol and a receiver 108 compatible with the MPTCP protocol. The source 101 and the node 102 belong to a first LAN, referred to as the source LAN. The receiver 108 and the node 107 belong to a second LAN, referred to as the receiving LAN. The nodes 103 to 106 belong to a WAN. The source 101 is capable of communicating over four different paths with the receiver 108 using an MPTCP connection. An initial MPTCP subflow, denoted TCPId0/0, uses a first path, and three additional MPTCP subflows, denoted TCPId1/1, TCPId2/2 and TCPId3/3 use the remaining three paths. In the notation TCPIdi/j, the suffix i/j indicates that the MPTCP subflow uses a source address identifier (address ID) i and a receiver address identifier j.
The transport protocols suited to a multipath communication mode, such as for example the MPTCP protocol, cannot manage an opening of new intermediate communication paths in a network, an intermediate communication path being defined as a path between an INC and a receiver or between two INCs.
FIG. 2B repeats the communication network 100 described in relation to FIG. 2A and illustrates certain limitations to the MPTCP protocol as currently defined. In FIG. 2B, a new intermediate path 109 of the WAN type opens during an MPTCP connection. The MPTCP protocol does not allow to detect an opening of an intermediate path during a MPTCP connection and even more so does not allow to use this new path. Consequently opening the intermediate path 109, which could potentially enable the source 101 to communicate with the receiver 108 at a higher rate, in reality has no beneficial effect.